…nger uses

D4b moved the materializer from a whole-universe single frame to per-symbol
streaming. Two tools still described the old shape, which is the exact failure
mode this repo has paid for three times (#76, #78, #82): the behaviour changed
and the sentence about it did not.

* qt/saturation_probe feasibility mode measures the PRE-D4b engine. Its item 3
  said "the materializer loads every symbol into ONE frame", present tense. It
  is now marked HISTORICAL -- it is what that geometry would have cost, i.e. the
  reason it was replaced, not what runs today -- and the module header points at
  --mode stream-scale for the current path. Items 1, 2 and 4 are facts about the
  DATA, not the engine, so they stand as written.
* qt/factor_hotpath_smoke loads its 40-symbol sample into one frame in BOTH
  arms. What it measures is unchanged and still the point (repeated 1min read +
  normalize vs paying it once), but the NAIVE arm is no longer a picture of the
  engine's memory profile, and a reader could reasonably take it for one. Said
  so, with a pointer to the tool that does measure the real path.

Deliberately NOT swept: the eleven eval runners' "the multi-year all-symbol
minute panel is NEVER materialized". Those describe the runners, which still
stream per symbol -- a careless sed here would turn true statements false, which
is the trap #82 called out by name.

Both tests could have agreed for the wrong reason if their fixture drifted, and
neither would have said so:

* the early-saturation test borrowed "the dense symbols stop short of the floor"
  from the test above it, in prose. On a shorter fixture the first expansion
  chunk would already reach the floor, both sides would load the same bars, and
  the comparison would pass while exercising nothing. It now records the load
  starts itself and asserts the early stop.
* the cross-section test compared the streamed values against the one-frame
  reference with an extra universe member present. If that member changed
  nothing, agreement would be equally consistent with a per-symbol cross-section
  -- exactly the failure it is meant to exclude. It now asserts that the extra
  member actually moved existing cells (measured: it does).

…seline

The feasibility probe's section 5 left "per-symbol saturation: implemented and
accepted" open, and said explicitly that it had NOT reconciled intraday_amp_cut
end to end. Section 6 closes that in the same file, so the before and the after
sit next to each other instead of in two documents that can drift apart.

Recorded, all measured:

* cell-by-cell reconciliation on REAL bars (40 symbols x 6 months) against the
  geometry that was replaced -- every symbol in one frame. Index identical and
  NaN-set difference ZERO on all ten factors; five bit-identical, the other five
  within 3.3e-14 (pandas rolling accumulation over a differently-sized prefix,
  the residual D2/D4 already catalogued). The NaN column is the load-bearing one:
  a finite<->NaN flip is a coverage change, not a float artefact.
* the scale proof on the real evaluation plane for the riskiest factor
  (intraday_amp_cut, the only pooled x cross-sectional one): nominal largest
  frame 0.0656 GB, PEAK RSS 0.964 GB against 56 GB available, 995 of 995 symbols
  present, live_calls 0. The two numbers are reported separately because the
  probe measured frame:peakRSS at 2.2-2.45x and the nominal figure alone
  understates the requirement by about half.
* where the cost actually falls: a dense symbol saturates in ONE provider call
  (0.59 s), a late-listing symbol takes 40 (14.95 s) because it re-reads its own
  history on every expansion chunk. 40 is exactly the chunk arithmetic. That cost
  now lands on those 84 symbols instead of dragging all 995 -- which is the point,
  since the all-995 version did not fit in memory at all.

Also disclosed: wall times are upper bounds (other acceptance jobs were running
on the same box); the memory figures are per-process high-water marks and are
not affected. And the expansion STEP SIZE is a documented non-correctness knob
that could cut those 40 reads, but changing it is still a load-geometry change
that owes its own reconciliation, so it is left to D5 rather than bundled here.

CROSS_SECTIONAL_MINUTE_FACTORS was a declaration with a comment explaining it.
The comment is true today; nothing made it stay true. A minute factor that later
grew a cross-sectional step without being added to the set would be streamed
with an identity combine and would silently return per-symbol values -- the same
class of defect as splitting around the whole factor, which this step exists to
prevent.

The classification is now derived and asserted on every bound factor, in both
directions: a factor is per-symbol pure iff splitting around the WHOLE factor
reproduces the whole-universe values. Nine must survive that split bit-identically
and intraday_amp_cut must not. Both halves are non-vacuous (the whole-universe
side is asserted to have finite values first).

…tries

One factor per load geometry, on the real evaluation plane, one process each:

* intraday_amp_cut_10   (pooled x CROSS-SECTIONAL) peak RSS 0.964 GB, 1990.5 s
* ridge_minute_return_20 (pooled)                  peak RSS 0.854 GB, 1133.7 s
* jump_amount_corr_20    (bounded)                 peak RSS 0.730 GB,  417.7 s

That is complete coverage of the geometries, not a sample of the factors: every
minute factor takes one of these three paths. All three carry 995 of 995 symbols
and live_calls 0.

The peak sits in a 0.73-0.96 GB band regardless of factor or output size, because
it is set by one symbol's bars plus the daily panel and not by the universe --
which is the property that makes the run possible at all, against the 52.7 GB
nominal / ~115 GB peak the replaced geometry needed. Wall time orders exactly by
geometry: no expansion < 20-chunk expansion < 60-day-chunk expansion.

The remaining seven factors are deliberately not run here: that is the D5 full
run, not D4b's acceptance. The sweep skips factors already in its JSONL (verified
by running it again against a recorded factor), so D5 continues rather than
restarts.

…ED-1)

Review found the one real engine defect D4b introduced. The single-frame engine
was immune to a repeated symbol because the providers' isin filter is idempotent
-- whatever the caller passed, one row per name came back. Streaming iterates the
list, so a repeat is materialized twice.

Measured on the streaming fixture with two names repeated, before the fix:

  volume_peak_count_20   48 -> 56 rows, 8 duplicated (date, symbol) entries,
                         values unchanged (the factor is per-symbol pure)
  intraday_amp_cut_10    the same 8 duplicates AND ALL 48 shared cells changed

The second one is the serious half: a factor with a real cross-sectional combine
sees the repeated name twice in its date's cross-section, which moves that date's
mean and std for EVERY member. FactorValueStore.upsert's duplicated(keep="last")
would de-duplicate the ROWS while keeping the contaminated VALUES, so it would
land in a persistent artifact. No live path can reach this today (the service is
not wired to a runner until D6), which is why it is not a HIGH -- but the mirror
of it was already taken seriously: the engine re-filters what a PROVIDER returns
and explains that it owns that invariant rather than trusting an injected object.
The caller-side half of the same invariant was not owned. Now it is, in one place
at the engine's entry point, covering the daily path too.

DE-DUPLICATING RATHER THAN RAISING, and why: it reproduces exactly what the
single-frame engine returned for the same call, which keeps D4b a change of
memory profile and nothing else. A raise would be a new failure mode for input
the previous engine accepted -- a behaviour change in the opposite direction, and
one that belongs to whoever validates a universe, not to the value engine.

MUTATION (run): removing the call restores 56 rows / 8 duplicates / 48 changed
cells (probe asserted BEFORE trusting the test), test rc=1; restored rc=0.

… the trim test

Three review items, all in tests.

MED-2 -- the JC5 docstring stated its own reasoning backwards. It said leaving the
old mutation expression in place "would be a mutation test that cannot fail". It
would not: the assertion asserts that the drop HAPPENS, so an inert mutation makes
it impossible to SATISFY. The old expression went RED on the D4b engine; it was a
test that cannot pass. That distinction is not pedantic here -- the docstring was
invoking this project's heaviest methodology rule while describing its exact
opposite, next to a test whose real situation is the other rule (do not quietly
edit a test the new engine fails). Restated honestly, and the call count corrected
from 70 to 72: the earlier figure counted only the per-date fill and missed the
batch fill's 2 calls. Re-measured: 72 calls, 0 divergences, 20 zero-output calls,
all of them already vetoed by the guard above the symbol loop.

LOW-4 -- the per-symbol trim test covered only jump_amount_corr_20, whose
disagreement with the union rule shows up as a CHANGED VALUE. The other two
bounded factors express the same disagreement as a COVERAGE FLIP (NaN under the
union rule, finite under per-symbol) -- and finite<->NaN is precisely what
_assert_bit_identical singles out as the change this step must not make by
accident. Testing only the value-moving one missed the two that matter most. Now
parametrized over all three, derived.

Also recorded there, because it reverses this file's earlier framing: the trim is
not a conservative refinement of a correct rule, it CORRECTS a wrong one. Measured
across engines, all three bounded factors move exactly one cell and in all three
the per-symbol result equals the load-geometry-free truth while the union result
does not (jump_amount_corr 0.157115 union vs 0.090115 truth; the other two NaN vs
finite).

LOW-5 -- STREAMED_FACTOR_IDS was a hand-maintained tuple with nothing tying it to
the binding tables. A new minute factor could enter both tables, satisfy the
coverage test, and still slip past every parametrized reconciliation silently.
Derived from the binding table now, with the id round-tripped through the registry
so the derivation itself is checked; BOUNDED_FACTOR_IDS likewise.

…ee doc claims

NIT-6 -- --mode stream-scale reproduced the scale table, but NOTHING in the repo
reproduced section 6.1, the most load-bearing table in the document: a reviewer
could only re-derive it by writing their own script. The probe is already the
project's "committed, re-runnable instrument"; this holds it to that standard.
--mode reconcile runs the 40-symbol x 6-month comparison against the whole-universe
single frame and exits rc=1 if any factor's index or NaN set differs. Its output is
now transcribed into 6.1 literally, same columns and same order, so the two can be
diffed directly. Verified: the committed mode reproduces every number.

NIT-7 -- 6.1 never stated the reference's load depth, which is load-bearing: the
streamed side's depth is decided by saturation expansion for the 8 pooled factors,
so a shallower reference compares two different histories and a deeper one changes
the float-accumulation prefix. Stated (400 calendar days), with the reason, and it
explains why this table shows ~1e-14 residuals while a branch-vs-main comparison of
the real engine gets exactly 0.000e+00 -- there both sides load identically.

MED-3 -- 6.1 declared a policy this step does not actually keep: that finite<->NaN
flips are "never allowed here". per-symbol trim CAN produce them and measurably
does (two of three bounded factors); the 40-symbol sample simply has no symbol
sparse enough to trigger it. Corrected to say what is true: zero flips ON THIS
SAMPLE, with the one disclosed semantic change that can produce them named.

Direction reversal (new 6.5) -- this document warned that if D5 mismatches the D1
frozen baseline on sparse symbols, the trim is the first place to look. That is
backwards, on the safe side. Cross-engine measurement, three bounded factors, one
cell each: per-symbol == the load-geometry-free truth in all three, union != truth
in all three. The union rule was not looser, it was WRONG (red line #6: a value
that depends on load geometry). And the eleven eval runners read each symbol's
whole window with no union trim at all, so per-symbol moves TOWARD the frozen
baseline, not away. The warning is restated pointing at saturation depth and
anchor truncation, which are the named attribution items.

…tor must fail

Deriving the parametrize lists from the binding tables only guarded factors
ADDED to a table. Review measured the open direction: dropping one factor from
both tables left this file at 53 passed and the suite at 2169 passed, all green,
with the factor silently absent from every reconciliation. The source of truth
is now the set of Factor subclasses defined under factors/compute/minute, so a
new factor file that nobody classifies fails here. Mutation witness: removing
PeakIntervalKurtosisFactor from both tables (occurrences 4 -> 0, asserted before
running) turns this test red; restoring makes binding.py byte-identical and the
file green at 58.